\chapter{Conclusions} \label{roz:conclusion}

\section{Final remarks}
Software engineers: design architects, developers and project managers are likely to rely on scientific results, especially those research on software quality. That s why, metrics should be reliable because they are used to measure if following components of a system keep the quality or they are used to predict effort for maintenance activity and identify system components that need particular attention. 

From one side, software metrics verify the laws and rules of structural and object--oriented programming, so they are a great support for good coding practise, but from the other side they are not developed and research commonly by academic and professional development environment. That is why, some of metrics assumptions are out of date and does not take into consideration the newest aspects of modern programming.

Software engineers are able to rely on the tools implementing these metrics. They allow to quantify the software quality and deliver information needed to take a decisions during designing and implementing process. However, the threshold values defined in these tools are not based on any theoretical and practical research so it should be treated with reserve. The main advantage of metrics tools is a fact that they are available for free in most of the cases. The leader of final classification is definitely SonarQube that is commonly used in many professional and commercial projects. The range of provided metrics is quite impressive and it is still developed. 

From the scientific point of view, the results of measurement using described tools are strongly dependent on the implementing tools, so a validation supports the applicability of some metrics as implemented by the given tool. 

The practical approach described in Chapter~\ref{roz:metrics-practic} shows how software metrics could be used in arbitrary programming project. The results of measurement show areas of increased risk of faults appearance and potential maintenance problem. However, it was mentioned that the threshold values could be freely changed and it does not mean that developers should refactor its code. 

Undoubtedly software metrics are one of the first instruments available to project development management, because they are early indicators to risk-prone issues. In context of each software project, the project managers are able to formulate their own metrics and leading metrics tool in order to address company's unique strategic goals, priorities and clients custom needs and expectations to fully satisfy their requirements. 

\section{Further development}
This thesis enhances the set of commonly used software metrics and presents the advantages and disadvantages of metrics tools. Like most of research, this study has several limitations, because it covers only a subset of metrics and tools. This research needs to be further extended with wider set of software metrics to evaluate many more measurements and comparison.

Using metrics in practise is not a easy approach, because it requires an experience and developing own skills to provide a good software products. One of the further development for software metrics  is to determine generic and unique threshold values characteristic in given programming language or environment. Such approach opens an opportunity to define own, well-designed and described metrics.

Another further consideration is developing set of tools that implements already existing or newly defined metrics. Currently, many tools are either out of date or not developed any more. This is a kind of market that business niche has created.   

The last consideration that is not appreciated in context of software metrics is fact that they are a perfect \textit{tool} to teach the good coding practise and show the area of commonly made mistakes in given programming language.